Where Did All the Designers Go!

Edited by Nina Miller

 

 

 

Introduction

As a consultant, you often find yourself looking at other people's code. That is because you are often asked to finish an existing product, or to make an existing product work correctly. One of the most frustrating aspects of inheriting preexisting code is that invariably the code was written with only rudimentary consideration of the design process. "How can that be?", you wonder. "I thought all software programmers are designers by nature." If you believe this, you've swallowed the biggest myth of all time. Software developers are rarely designers. In fact, I have come across so few real software designers over the years that I ask myself, who is even creating the software products for our industry? What has caused this dearth of design talent in the industry? After some thought and investigation, I have compiled a list of reasons as follows:

1) Software design is not taught in our universities.

Why not? Why isn't the most important aspect of writing software the first required course for this major in in universities and other learning institutions?? Why is Software 101 about writing code or about understanding some computer language? Professors are more interested in the number theory behind the software. Concepts like recursion and data structures are a lot more sexy in the academic world than iterative development and refactoring and software testing . When computer programming first entered the curriculum about 25 years ago, it wasn't even an engineering discipline in many schools; computer programming was in the math department! Have we come a long way since then? I'm not so sure.

2) Job Talent Scouts are only looking for Coders.

Part of the problem is marketing. Job listings cite implementation-specific skills like Java or C++ or C#. Rarely does a job description list in its criteria a proficient, experienced software designer. Recruiters pick up on this and feed their clients what they are demanding. Recruiters actually scan resumes for "implementation-oriented" key words. The result? A job market with a glut of implementers and no designers.

3) Code is outsourced.

Companies now outsource most of their coding. They think they know what they need and the skills required to do a competent job and they provide a basic requirement spec. The company is on a tight deadline, and demands an unrealistic turnaround. The contractor doesn't waste time with something as lowly as design. He goes straight to the code with some vague notion of "n-tier development" in the back of his mind.

4) There are no credentials for Software Engineering

Before you go to med school you need to take the MCAT's, to go through a stringent application process, to get in, and survive 4 or more grueling years. When you leave medical school you are certified and licensed to practice medicine. You then complete a residency to specialize in your field in order to independently treat patients. To become a software engineer, you merely just say it on your resume. "Hi, I'm a software engineer!" And what does that mean to a potential employee? It means anything from writing a VB Program for balancing a checkbook to architecting a complex aviation system. It is not clear to anyone what qualifies someone as a good software engineer. Granted, when someone applies for a job as a software engineer, the employer should know exactly what to ask the candidate to determine if he knows something about software engineering. But in my entire career, I rarely have been tested on my software engineering skills. A prospective employer is more likely to ask "How do you put up a message box in windows SDK?". The questions tend to be implementation specific. I remember taking a test for one of the top software consulting firms on Wall Street and the entire exam consisted of esoteric implementation-specific questions about C#. Great. You wonder if that firm ended up with a bunch of jeopardy contestants who would be wizzes in the category... "I'll take, "What is the IL code for a finalize block for $200?".

5) Employers use poor judgment

Employers need to be educated also. If the senior software engineer in your company is not doing any design, do you think that the manager who hired him is even aware of it? Those managers are asking the same vanilla questions. "We are developing in C#, Do you know C#?". "Have you ever used STL?". "How good is your JavaScript?". Again, employers are focused on the tools and not the nuanced skills essential to creating a quality product. Admittedly, a few knowledgeable interviewers have requested custom-tailored designs for their systems. These managers value programmers who understand the importance of design.

6) Engineering and Programming have gotten a Divorce.

Engineers are always taught to design first and implement later. When you design a chip, you don't create it immediately. You draw it on a CAD System, test it, simulate it, and are trained to follow a process which begins with concept and design. If a chip is poorly designed, the host company will spend fruitless money creating the physical circuit. When an aeronautical engineer designs an airplane, does he just slap a set of wings on a piece of metal and throw it in the air to see if it can fly? No. He designs it on a CAD system, simulates stress under different conditions, models the airplane as a system that must meet rigorous criteria, tests it, tests it, and tests it some more. The airplane designer needs to meet a set of strict standards in order to pass the spec. And what would happen if the aeronautical engineer did not design and test thoroughly? I don't want to think about that.

What about the software engineer? How analogous is programming to other engineering disciplines? Not much. There is too much temptation to rush to the implementation phase. Heck, why design anything when you can already start coding and see what happens? Right? Developers don't think ahead to the cost of troubleshooting and correcting software that hasn't been designed effectively. It's not as black and white as a bad yield of 1,000,000 defective processors, or a poorly crafted airplane. Because software is more intangible, it's easier to justify a shoddy job on development - after all, it can always be "cleaned up" later. "If the software isn't working right, I'll just fix it... just a couple lines of code..."

7) Engineering Talent has fallen by the wayside.

If it's hard enough to find a programmer, how the heck am I going to find a good software designer? With the lack of people going into IT these days (due in part to the Internet boom-bust in the late 90's), most managers will take what they can get. As with any commodity, software talent is a matter of supply and demand. Given today's woeful under-supply of IT talent, the price for a programmer/designer is high. Start ups and small businesses with tight finances are more likely to hire someone out of school. Even large companies want to keep their profit margins high by paying for less expensive talent. There is nothing inherently wrong with an economical approach, but these employers are not aware that schools are graduating programmers with no understanding of design. The reality is that good design technique is learned on the job, and so those who are skilled and proficient are invariably seasoned programmers with many years under their belts.

Let's ask the question another way. Would you want recently graduated engineer designing the airplane you fly on? No. You would want that engineer to work for several years under a mentor who would teach the ropes of designing a solid airplane How about the software engineer? Would you want someone with no experience to code the heart and soul of your business? Probably not unless they were working with a senior software designer. But with the lack of IT talent compounded with a lack of design talent, plus the aging and retiring of baby boomers, who made an impressive contribution to the software industry, the core products of many businesses are created by programmers with zero design experience Businesses don't understand that programming is like designing an airplane until it's too late.

Conclusion

How do we solve the problem of poorly trained software developers? How can we get the current pool of software developers to think like designers? First, universities and other centers of learning need to emphasize software design over pure theoretical programming. If I were a teacher in the software field, I would not introduce any computer language in the first semester. Design concepts would be the foundation of any computer course. Secondly, employers need to reframe job descriptions so that implementation-specific languages are not the only requirement. If you are an employer, screen potential candidates for design. Also, consider hiring someone whose expertise is design and architecture. They can work with an implementer after the design is finished. Software products should be from the brainchild of 90% design and 10% implementation rather than current, dismal 10% design and 90% implementation. The benefits of concentrating on design first range from better maintainability of existing products to easier reuse for spinning off additional products. Whether it's airplanes, cars, molecules, clothing, or software, a focus on design over implementation will in the end determine the quality of your labors.